In the latter half of the twentieth century, there began a phenomenon known as the information revolution. While the information revolution is a historical development broader in scope than any one event or machine, no single device has come to represent the information revolution more than the digital electronic computer. The development of computer systems has surely been a revolution. Each year, computer systems grow faster, store more data, and provide more applications to their users.
A modern computer system typically comprises hardware in the form of one or more central processing units (CPU) for processing instructions, memory for storing instructions and other data, and other supporting hardware necessary to transfer information, communicate with the external world, and so forth. From the standpoint of the computer's hardware, most systems operate in fundamentally the same manner. Processors are capable of performing a limited set of very simple operations, such as arithmetic, logical comparisons, and movement of data from one location to another. But each operation is performed very quickly. Programs which direct a computer to perform massive numbers of these simple operations give the illusion that the computer is doing something sophisticated. What is perceived by the user as a new or improved capability of a computer system is made possible by performing essentially the same set of very simple operations, but doing it much faster.
Complex systems may be used to support a variety of applications, but one common use is the support of large databases, from which information may be obtained. Conceptually, a database may be viewed as one or more tables of information, each table having a large number of entries or records (analogous to rows of a table) of a common format, each entry having multiple respective data fields (analogous to columns of the table). Database management software provides the ability to define the parameters of the database, to create new database records, edit existing records, and so forth. In particular, large databases usually support some form of database query for obtaining information which is extracted from selected database fields and records. Operations performed by database management software, and particularly database queries, can consume significant system resources.
A large database is often intended to provide information to a variety of users. Many computer systems containing large databases provide database access according to a client-server model, in which the user of the database (the client) requests some service of the database (such as the execution of a query against information in the database), and the database management software functions as a server to perform the requested service using the database information and return results (e.g., requested information, acknowledgment that an operation was performed, etc.) to the client. Use of a client-server model facilitates access to database information where the clients are located at different computer systems, often physically remote from the database system.
Client-server interaction with one or more databases can be very complex. The scope and type of information stored may vary. Databases have a particular structure, including one or more tables, structure of entries within each table, auxiliary database structures such as indexes, histograms, etc. for assisting queries, and so forth. It is desirable to shield users and or user applications from these details of database design. A family of middleware applications, herein called a “middle tier facility” or “middle tier”, is often interposed between the clients and the database can provide a convenient means for accessing one or more databases. To the client, the middle tier appears as the server. I.e., the client's direct interaction is with the middle tier, which services its requests. The middle tier may contain any of various complex applications user for servicing client requests. Servicing at least some requests requires access to data in a database, although in many cases there will be other requests can be serviced entirely within the middle tier, without accessing a database. To the database, the middle tier is an intermediate application which represents multiple clients in their transactions with the database. The middle tier may support access to multiple databases, and some requests may require that data be obtained from multiple databases to satisfy the request. Data obtained from a database might be returned directly to the client, or might be processed by the middle tier to generate other data, which may be returned to the client and/or re-stored in the database. A form of client-server environment in which a client accesses a database through such middleware is sometimes referred to as a three-tier environment.
An example of such a middle tier is a facility which handles requests generated from multiple clients running interactive web browsers to access data contained in one or more databases. Typically, a user of a web browser has no knowledge of the design details of a database, and only knows the type of information in which he is interested. A middle tier facility converts the requests from the web browsers of the clients to some appropriate form for accessing a database. In many cases, a single request may require the middle tier to access multiple databases and process resulting data for the client.
It is possible to design a middle tier facility as custom-written computer programming code to support a known set of clients and access a known set of databases. However, it is generally much easier to design a middle tier from an existing shell or framework, which is then customized for the particular application or applications. Such a shell or framework for a middle tier is referred to herein as an “application server”. An application server typically contains a collection of generic interfaces for different types of databases, as well as other frequently used functions or procedures. One or more customized middle tier applications run in the application server and utilize its functions to access the databases. Such an application server may be offered in an object-oriented programming form as a hierarchy of pre-defined classes, methods and objects, which may then be customized by extension. However, an application server need not be designed using object-oriented programming constructs.
In a typical environment, the middle tier facility resides in a different computer system from the databases, and communicates with the databases across a network. The applications running in the application server require access to specific records of the database to service client requests. The application server forwards database access requests across the network to the database or multiple databases, and receives selective database records responsive to these requests via the network. The application server temporarily stores these records in a local data structure, which serves the function of a cache. These records are then accessed by the applications to generate specific data required to satisfy the requests by the clients.
In an application server it is desirable to use a common generic interface to access records of a database, the common generic interface being potentially invoked from multiple different middle tier applications or procedures. Because the generic interface must support multiple different applications, it is designed to access any information which may be required from the database. Specifically, in accessing a database record, the generic interface is typically designed to obtain a full database record, i.e., all fields in a database record, whether or not all fields are actually used by the requesting application to satisfy the client request.
Where database records are being transferred across a network and stored in a local data structure in the application server, significant network bandwidth and local storage capacity may be consumed in transferred records fields which are not actually used by the middle tier applications to satisfy client requests. In such cases, it would be desirable to transfer and store only the fields which are actually required to satisfy client requests in order to reduce the consumption of network and local resources. The problem is particularly acute where generic interfaces are used, as in the case of an application server shell or framework for supporting multiple middleware applications. It is possible to design custom interfaces which will request only the minimal amount of data required from the database, but the construction of custom interfaces involves reduces the portability of applications, the re-usability of code, and generally increases the burden of code development and maintenance.
A need therefore exists for improved techniques for accessing databases in a network environment which both avoid excessive utilization of network bandwidth and other system resources, and at the same time offer the advantages of generic interfaces provided by an application server shell.